USA Bestseller/USA BESTSELLER Vol 1-95 (Hepp-Computer)(1995).iso/e199/release.not

Text File | 1994-04-27 | 13KB | 251 lines

The following are release notes for version 4.04 domestic Jumbo Colorado
Backup for DOS release.  Below is a list of parts affected by this release:

    88-0147-404  SFTWR,JUM,5H,DOS,ENGL,DIST
    88-0148-404  SFTWR,JUM,3L,DOS,ENGL,DIST
    88-0206-001  SFTWR,JUM,3H,WDOS,ENGL,DIST ** This is the combo disk for
             CBD
                                                                and CBW.
                                                                This release includes the following enhancements over 4.03:

1.  The minimum memory requried to run tape/diagnostics has dropped to 400K.
420K is still the published minimum in the User's Guide.

1.  Colorado 700 (or 500 or Jumbo 500 or Buzzard, whichever name is being
used now) is supported.

2.  Diagnostics for Jumbo is now available.  This functionality is supported
as a command line option (TAPE DIAGNOSE).  Originally this software was a
stand alone tool, but to save space on the distribution disk it was integrated
into the tape software.  The important thing to note is that, although the
tape software and diagnostics have been integrated, you cannot access the
diagnostic functionallity from the tape menuing software.  Likewise, you
cannot access the tape software from the diagnostic menus.  An addendum to the
Colorado Backup for DOS User's Guide will ship with the product until this
documentation can be integrated into the manual.  Please refer to the addendum
or user's guide for details on the operation of the diagnostic software.  The
rest of this section contains some special hints and trouble shooting ideas.

Base Address Test:
The purpose of the base address test is to verify that the selected base
address does not conflict with other I/O cards in the system.  This test
applies only to CMS controller cards, since the base address for native
floppy controllers is fixed at 03F0H.  The tape controller uses sixteen
consecutive addresses starting at the base address.  If the address range
used by another card overlaps the tape controllers address range, a base
address conflict exists.  The base address test performs a series of reads
and writes to the address range.  The tape controller will respond in a
unique manner to the read/write sequence, thus allowing us to recognize
that it can be accessed at that address range.  With this type of intrusive
testing, it is possible to cause the system to hang.  This is not a bug in
the diagnostics software.  The problem is that there is no way of knowing
how some I/O cards will respond to read/write sequences to their registers.
For example, the NE-2000 network card will hang the system if a read is done
at the last byte in the address range.  Since the base addresses are tested
in ascending order, the user may never get past a base address that hangs
the computer.  To resolve this, the base address test keeps track of which
base addresses have caused the system to crash.  The list is maintained
transparently in TAPE.CFG.  In the Confidence Test, the base address test
will automatically skip any addresses which hang the system.  If the user
selects I/O Conflict Test from Advanced Options, they will be warned that
previous attempts to test a base address caused the system to hang, but they
will have the option to override the warning.  With this arrangement, the
user only has to experience, at most, one crash per bad I/O address.  Keep in
mind that for the majority of I/O cards, the base address test is benign.

IRQ Conflict Detection Test:
The purpose of the IRQ Conflict Detection Test is to determine whether a
specific IRQ can be used by the tape controller card.  Similar to the base
address test, this test applies only to our cards.  The IRQ test will
configure the tape controller card for a specific IRQ and then attempts to
generate 100 consecutive interrupts.  For each interrupt, the interrupt
latency is measured.  If all 100 interrupts are received and the maximum
latency is less than 500 uS, the interrupt passed the test.  The test
results indicate two levels of non-conflicting IRQ's ("Passed" and
"Recommended").  If the interrupt was masked prior to the test, the IRQ is
"Recommended".  If the interrupt was unmasked, the IRQ "Passed".  In both
cases, no conflict was detected; however, the fact that the IRQ was unmasked
seems to indicate that someone or something made use of the IRQ since the
system was booted (all IRQ's are masked by default at system boot time).
When selecting an IRQ, the "Recommended" IRQ's are obviously preferred.
But if none exist, select one from among those that "Passed".  The order of
preference is subject to debate, but my experience leads me to suggest the
following:

   Order of preferrence for IRQ selection:

    IRQ6
    IRQ5
    IRQ7
    IRQ2
    IRQ3
    IRQ4
    IRQ10   (TC-15 only)
    IRQ11   (TC-15 only)

The reason that the IRQ test prompt the user to reboot after the test is
complete is because the IRQ test may cause drivers and I/O cards to become
disabled due to starvation.  For example, many network cards "ping" the
server on a regular interval.  When the IRQ used by the network card is
tested, the connection to the server is lost.  Having the user reboot allows
any side effects caused by the IRQ test to be corrected.  Most of the time,
you can side-step the reboot if you can live with the side effects (if any).

Communication Test:
The communication test verifies that communication can be established between
the system and the tape drive.  The test progresses incrementally, testing
communication between each functional component in the communication path.

    System to controller chip (via system bus)
    Controller to firmware (via data cable)
    Firmware to drive electronics (via firmware commands)

The communication executes the following steps:

   1)  Reset the floppy controller chip
   2)  Attempt a drive reset
   3)  Verify the data cable physical connections
   4)  Verify the data cable via blind communication
   5)  Test ability of drive to send/receive bytes by querying for the drive
       status and firmware version.

Because most of the lines in the data cable are not tied to accessible
controller chip registers, it is not possible to individually verify each
line.  The lines which can be verified are INDEX, WP, TRK0 and STEP.  Since
the WP and TRK0 lines are tied to registers in the controller chip, they can
be verified physically as well as functionally.  If the data cable is connected
upside-down, the test can detect it because the WP line will be grounded.
If the data cable is offset by a row (vertically misaligned), the TRK0 line
will be grounded.  When the test is first started, it is important that there
is not a tape cartridge inserted into the drive.  When the drive reset is
issued, the drive assumes a power-on state.  If there is a tape in the drive,
the autoload will proceed, which will conflict with the blind communication
and cause commands sent to the drive (during autoload) to be ignored.
During functional verification of the data cable, the user is prompted to
insert and then remove a write protected tape cartridge.  This has the effect
of "wiggling" the WP and TRK0 lines.  The firmware commands issued (via STEP
pulses) to sense the drive status causes transitions to occur on the STEP
and INDEX lines, allowing verification of those lines as well.  In addition,
the write protect sense switch is verified and reconciled against the state
of the WP line.  Throughout the test, interrupts are generated by the floppy
controller.  These interrupts are counted and any missed (or superfluous)
interrupts are reported.

Read/Write Test:
The read/write test verifies the ability of the tape drive to write and then
read a large block of data.  The block consists of greater than 1 but less
than 2 tracks of randomly generated data.  The actual number of segments
written depends on the capacity of the tape.  The block size is set so that
regardless of where on the tape the data is written, the drive will read/write
in both directions.  The random data pattern is repeated for each 32K segment.
The 3K ECC (error correction code) is not computed, applied or used.  The raw
data is written and read without error correction.  Errors encountered during
the read phase are reported in the following manner:

    Bad Sectors = Number of sectors with 1 or more bad bytes
    Bad Segments = Number of segments with 1 or more bad sectors

The Read/Write test will write to and read from an unused section of the
users tape.  The test will not destroy or affect any good volumes stored
on the tape.  The test requires up to 5700 Kbytes (depending on the
type of drive) of available space on the tape.  The space is used
temporarily (only for the duration of the test).  Due to the way that
tape volumes are maintained on the tape, it is possible to have a tape
that reports > 5700 Kbytes free (by View Tape Status) but is reported
by the Read/Write test to be full (less than 5700 Kbytes free).  Here's
an example of how this can happen:

A) Consider a tape that contains 4 volumes as illustrated in the diagram
   below.  Tape Status would report that the tape has 3 Mb available.

 ─┬────┬────┬─────────────────────────────┬───────────┬─────────────┐
  │    │    │                             │           │             │
  │Vol │Vol │       Vol (100 Mb)          │ Vol (2 Mb)│ free (3 Mb) │
 ─┴────┴────┴─────────────────────────────┴───────────┴─────────────┘


B) The user then performs a quick erase on the last two volumes.
   The tape now has 105 Mb free.

 ─┬────┬────┬─────────────────────────────┬───────────┬─────────────┐
  │    │    │                             │           │             │
  │Vol │Vol │       EVol (100 Mb)         │EVol (2 Mb)│ free (3 Mb) │
 ─┴────┴────┴─────────────────────────────┴───────────┴─────────────┘


C) The user does a small backup which overwrites a portion of the
   previous volume, resulting in the remainder of the volume to be
   marked as a Bad Volume (BVOL).  The tape now has 100 Mb free.

 ─┬────┬────┬──────────┬──────────────────┬───────────┬─────────────┐
  │    │    │          │                  │           │             │
  │Vol │Vol │Vol (5 Mb)│ BVol (95 Mb)     │EVol (2 Mb)│ free (3 Mb) │
 ─┴────┴────┴──────────┴──────────────────┴───────────┴─────────────┘


D) The user inserts the tape and attempts a Read/Write test.  The
   Read/Write test uses the following alorithm to decide where to
   write the test data:

    1) Check for unused space at the end of the tape.  If this
       fails, continue to step 2.

    2) Look at the previous volume, if it is an EVOL, continue
       with step 3, otherwise goto step 5.

    3) If there is > 5700 Kbytes from the beginning of this
       EVOL to the end of the tape, go to step 4, otherwise,
       repeat step 2.

    4) Success!  Start writing the Read/Write test data here.

    5) Failure!  The tape is full.

   The decision was made not to attempt to overwrite Bad Volumes
   due to the fact that they are not maintained in natural (sequential)
   order in the Volume Table at the start of the tape.  Volume table
   entries for Bad Volumes are always placed at the end of the table.
   To solve the problem the volume table entries would have to be sorted
   by start-segment and then processed.  Due to time constraints,
   the previously described algorithm was implemented.  Customer Support
   technicians should be aware of this so that they can respond if
   this scenario occurs.

XX. On-line help text is now read directly from the language text file tape.txt
on a demand basis.  As a result of the changes to the on-line help system, an
additional file ("TAPE.NDX") must be present in the install directory to run
the software.  TAPE.NDX is the help index file and it is created by
INSTALL.EXE when the software is installed.  If this file is inadvertently
deleted, modified or otherwise compromised, it can be recovered by
re-installing the software.



3.  The installation utility "INSTALL.EXE" has been modified to support a
single disk implementation of CBD and CBW Lite.  The changes consist of

xx. USING QEMM's VIDRAM UTILITY:

The use of the Quarterdeck utility VIDRAM.COM that is shipped with QEMM
is not supported by the tape/diagnostics software.  VIDRAM allows
graphics RAM to be configured as conventional memory by the memory manager.
On some systems, the only side effect is that the screen colors will be
"mangled".  However, some systems may hang or report a memory allocation
error and abort.

xx. We now complete certification without any failures, but with a couple of
notes, such as Mac directory restrictions and comments.

Certification issues fixed for 4.04
------------------------------------
1) Wide and deep directories are functional at Novell's specs.
     Note: This change should also fix the error 30000 about allocating too              many directory handles on the server (what I said earlier).
2) Odd character names
3) Volume restrictions for 3.x
4) System bit on directories for 2.2
     (NOTE: the private bit on directories will not (cannot) be backed up.)

There has been an error 30000 on allocating directory handles on the server (something to that effect) that should be fixed with the new algorithm for searching the disk.